@gregorydemay I did quite a bit of experimenting here with different solutions to make this as easy to use as possible despite all the generics involved with tower middlewares. For example I considered an enum wrapping single requests and batch requests, some traits for request/response pairs that are valid JSON-RPC calls (i.e. HttpJsonRpcRequest/HttpJsonRpcResponse and HttpBatchJsonRpcRequest/HttpBatchJsonRpcResponse), etc. In the end I think things as they are now are a pretty good tradeoff between being generic and usable, but let me know if you have any specific ideas/concerns and I can let you know why I didn't go in those directions.

@gregorydemay One thing in particular I thought we could discuss: JSON-RPC batch responses are not necessarily in the same order as the requests. At some point, we will need to match responses to requests using IDs. I actually thought we could do this in the response filter where we check for consistent IDs. We could then return a vector of Results ordered like the requests, where each element is either the response for the request in the same index, or some sort of a MissingResponseId error.

Generally, I think in the end we might have per-response errors and overall errors for the batch so the return type from the Service for batch JSON-RPC should probably be something like Result<Vec<Result<Response, ErrorType1>, ErrorType2>. We would then have to think what to do in cases like: some IDs are unexpected in the response, but some responses are indeed there (we don't want to return an error for the batch as a whole, but what do we do with the unexpected responses?). Maybe a different struct to store the response of a batch JSON-RPC request would then make more sense? WDYT?